Method and apparatus for releasing sidelink radio bearer in a wireless communication system

ABSTRACT

A method and apparatus are disclosed from the perspective of a first UE (User Equipment) to indicate a network node for releasing SLRB (Sidelink Radio Bearer) or SL-DRB (Sidelink-Data Radio Bearer). In one embodiment, the method includes transmitting a first RRC (Radio Resource Control) message to a network node for requesting sidelink resource, wherein the first RRC message includes a PFI (PC5 QoS Flow Identifier) of a PC5 QoS (Quality of Service) flow in a first list of PC5 QoS flows. The method also includes receiving a second RRC message from the network node, wherein the second RRC message configures a SLRB and maps the PC5 QoS flow to the SLRB. The method further includes transmitting a third RRC message to the network node if the PC5 QoS flow is deactivated or released, wherein the PFI of the PC5 QoS flow is removed from a second list of PC5 QoS flows included in the third RRC message.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 16/935,807, filed Jul. 22, 2020, which claims the benefits ofU.S. Provisional Patent Application Ser. No. 62/882,199 filed on Aug. 2,2019 and U.S. Provisional Patent Application Ser. No. 62/931,485 filedon Nov. 6, 2019, the entire disclosures of which are incorporated hereinin its entirety by reference.

FIELD

This disclosure generally relates to wireless communication networks,and more particularly, to a method and apparatus for releasing sidelinkradio bearer in a wireless communication system.

BACKGROUND

With the rapid rise in demand for communication of large amounts of datato and from mobile communication devices, traditional mobile voicecommunication networks are evolving into networks that communicate withInternet Protocol (IP) data packets. Such IP data packet communicationcan provide users of mobile communication devices with voice over IP,multimedia, multicast and on-demand communication services.

An exemplary network structure is an Evolved Universal Terrestrial RadioAccess Network (E-UTRAN). The E-UTRAN system can provide high datathroughput in order to realize the above-noted voice over IP andmultimedia services. A new radio technology for the next generation(e.g., 5G) is currently being discussed by the 3GPP standardsorganization. Accordingly, changes to the current body of 3GPP standardare currently being submitted and considered to evolve and finalize the3GPP standard.

SUMMARY

A method and apparatus are disclosed from the perspective of a first UE(User Equipment) to indicate a network node for releasing SLRB (SidelinkRadio Bearer) or SL-DRB (Sidelink-Data Radio Bearer). In one embodiment,the method includes transmitting a first RRC (Radio Resource Control)message to a network node for requesting sidelink resource, wherein thefirst RRC message includes a PFI (PC5 QoS Flow Identifier) of a PC5 QoS(Quality of Service) flow in a first list of PC5 QoS flows. The methodalso includes receiving a second RRC message from the network node,wherein the second RRC message configures a SLRB and maps the PC5 QoSflow to the SLRB. The method further includes transmitting a third RRCmessage to the network node if the PC5 QoS flow is deactivated orreleased, wherein the PFI (PC5 QoS Flow Identifier) of the PC5 QoS flowis removed from a second list of PC5 QoS flows included in the third RRCmessage.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a diagram of a wireless communication system according toone exemplary embodiment.

FIG. 2 is a block diagram of a transmitter system (also known as accessnetwork) and a receiver system (also known as user equipment or UE)according to one exemplary embodiment.

FIG. 3 is a functional block diagram of a communication system accordingto one exemplary embodiment.

FIG. 4 is a functional block diagram of the program code of FIG. 3according to one exemplary embodiment.

FIG. 5 is a reproduction of FIG. 7-1 of 3GPP TS 38.885 V16.0.0.

FIG. 6 is a reproduction of FIG. 5.10.2-1 of 3GPP TS 36.331 V15.3.0.

FIG. 7 is a reproduction of FIG. 5.2.1.4-1 of 3GPP TR 23.786 V1.0.0.

FIG. 8 is a reproduction of FIG. 5.4.1.1.1-1 of 3GPP TR 23.786 V1.0.0.

FIG. 9 is a reproduction of FIG. 5.4.1.1.3-1 of 3GPP TR 23.786 V1.0.0.

FIG. 10 is a reproduction of FIG. 6.1.1-1 of 3GPP TR 23.786 V1.0.0.

FIG. 11 is a reproduction of FIG. 6.3.3.1-1 of 3GPP TR 23.786 V1.0.0.

FIG. 12 is a reproduction of FIG. 6.3.3.3-1 of 3GPP TR 23.786 V1.0.0.

FIG. 13 is a reproduction of FIG. 6.3.3.4-1 of 3GPP TR 23.786 V1.0.0.

FIG. 14 is a reproduction of FIG. 6.2.2.3-1 of 3GPP TS 37.324 V15.1.0.

FIG. 15 shows Table 1 according to one exemplary embodiment.

FIG. 16 shows Tables 2 a and 2 b according to exemplary embodiments.

FIG. 17 shows Tables 3 a, 3 b, and 3 c according to exemplaryembodiments.

FIG. 18 shows Tables 4 a, 4 b, 4 c, and 4 d according to exemplaryembodiments.

FIG. 19 shows Tables 5 a, 5 b, 5 c, and 5 d according to exemplaryembodiments.

FIG. 20 is a flow chart according to one exemplary embodiment.

FIG. 21 is a flow chart according to one exemplary embodiment.

FIG. 22 is a flow chart according to one exemplary embodiment.

FIG. 23 is a flow chart according to one exemplary embodiment.

FIG. 24 is a flow chart according to one exemplary embodiment.

FIG. 25 is a flow chart according to one exemplary embodiment.

DETAILED DESCRIPTION

The exemplary wireless communication systems and devices described belowemploy a wireless communication system, supporting a broadcast service.Wireless communication systems are widely deployed to provide varioustypes of communication such as voice, data, and so on. These systems maybe based on code division multiple access (CDMA), time division multipleaccess (TDMA), orthogonal frequency division multiple access (OFDMA),3GPP LTE (Long Term Evolution) wireless access, 3GPP LTE-A orLTE-Advanced (Long Term Evolution Advanced), 3GPP2 UMB (Ultra MobileBroadband), WiMax, 3GPP NR (New Radio), or some other modulationtechniques.

In particular, the exemplary wireless communication systems devicesdescribed below may be designed to support one or more standards such asthe standard offered by a consortium named “3rd Generation PartnershipProject” referred to herein as 3GPP, including: TR 23.786 V1.0.0,“Architecture enhancements for 5G System (5GS) to supportVehicle-to-Everything (V2X) services (Release 16)”; TS 36.331 V15.3.0,“E-UTRA; Radio Resource Control (RRC) Protocol specification (Release15)”; TS 23.287 V110, “Architecture enhancements for 5G System (5GS) tosupport Vehicle-to-Everything (V2X) services”; 3GPP RAN2 #106 Chairman'snote; TS 38.885 V16.0.0, “NR; Study on NR Vehicle-to-Everything (V2X)(Release 16)”; TS 37.324 V15.1.0, “E-UTRA and NR; Service DataAdaptation Protocol (SDAP) specification (Release 15)”; and 3GPP TS38.331 V15.6.0, “NR; Radio Resource Control (RRC) protocol specification(Release 15)”. The standards and documents listed above are herebyexpressly incorporated by reference in their entirety.

FIG. 1 shows a multiple access wireless communication system accordingto one embodiment of the invention. An access network 100 (AN) includesmultiple antenna groups, one including 104 and 106, another including108 and 110, and an additional including 112 and 114. In FIG. 1, onlytwo antennas are shown for each antenna group, however, more or fewerantennas may be utilized for each antenna group. Access terminal 116(AT) is in communication with antennas 112 and 114, where antennas 112and 114 transmit information to access terminal 116 over forward link120 and receive information from access terminal 116 over reverse link118. Access terminal (AT) 122 is in communication with antennas 106 and108, where antennas 106 and 108 transmit information to access terminal(AT) 122 over forward link 126 and receive information from accessterminal (AT) 122 over reverse link 124. In a FDD system, communicationlinks 118, 120, 124 and 126 may use different frequency forcommunication. For example, forward link 120 may use a differentfrequency then that used by reverse link 118.

Each group of antennas and/or the area in which they are designed tocommunicate is often referred to as a sector of the access network. Inthe embodiment, antenna groups each are designed to communicate toaccess terminals in a sector of the areas covered by access network 100.

In communication over forward links 120 and 126, the transmittingantennas of access network 100 may utilize beamforming in order toimprove the signal-to-noise ratio of forward links for the differentaccess terminals 116 and 122. Also, an access network using beamformingto transmit to access terminals scattered randomly through its coveragecauses less interference to access terminals in neighboring cells thanan access network transmitting through a single antenna to all itsaccess terminals.

An access network (AN) may be a fixed station or base station used forcommunicating with the terminals and may also be referred to as anaccess point, a Node B, a base station, an enhanced base station, anevolved Node B (eNB), or some other terminology. An access terminal (AT)may also be called user equipment (UE), a wireless communication device,terminal, access terminal or some other terminology.

FIG. 2 is a simplified block diagram of an embodiment of a transmittersystem 210 (also known as the access network) and a receiver system 250(also known as access terminal (AT) or user equipment (UE)) in a MIMOsystem 200. At the transmitter system 210, traffic data for a number ofdata streams is provided from a data source 212 to a transmit (TX) dataprocessor 214.

In one embodiment, each data stream is transmitted over a respectivetransmit antenna. TX data processor 214 formats, codes, and interleavesthe traffic data for each data stream based on a particular codingscheme selected for that data stream to provide coded data.

The coded data for each data stream may be multiplexed with pilot datausing OFDM techniques. The pilot data is typically a known data patternthat is processed in a known manner and may be used at the receiversystem to estimate the channel response. The multiplexed pilot and codeddata for each data stream is then modulated (i.e., symbol mapped) basedon a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM)selected for that data stream to provide modulation symbols. The datarate, coding, and modulation for each data stream may be determined byinstructions performed by processor 230.

The modulation symbols for all data streams are then provided to a TXMIMO processor 220, which may further process the modulation symbols(e.g., for OFDM). TX MIMO processor 220 then provides N_(T) modulationsymbol streams to N_(T) transmitters (TMTR) 222 a through 222 t. Incertain embodiments, TX MIMO processor 220 applies beamforming weightsto the symbols of the data streams and to the antenna from which thesymbol is being transmitted.

Each transmitter 222 receives and processes a respective symbol streamto provide one or more analog signals, and further conditions (e.g.,amplifies, filters, and upconverts) the analog signals to provide amodulated signal suitable for transmission over the MIMO channel. N_(T)modulated signals from transmitters 222 a through 222 t are thentransmitted from N_(T) antennas 224 a through 224 t, respectively.

At receiver system 250, the transmitted modulated signals are receivedby N_(R) antennas 252 a through 252 r and the received signal from eachantenna 252 is provided to a respective receiver (RCVR) 254 a through254 r. Each receiver 254 conditions (e.g., filters, amplifies, anddownconverts) a respective received signal, digitizes the conditionedsignal to provide samples, and further processes the samples to providea corresponding “received” symbol stream.

An RX data processor 260 then receives and processes the N_(R) receivedsymbol streams from N_(R) receivers 254 based on a particular receiverprocessing technique to provide N_(T) “detected” symbol streams. The RXdata processor 260 then demodulates, deinterleaves, and decodes eachdetected symbol stream to recover the traffic data for the data stream.The processing by RX data processor 260 is complementary to thatperformed by TX MIMO processor 220 and TX data processor 214 attransmitter system 210.

A processor 270 periodically determines which pre-coding matrix to use(discussed below). Processor 270 formulates a reverse link messagecomprising a matrix index portion and a rank value portion.

The reverse link message may comprise various types of informationregarding the communication link and/or the received data stream. Thereverse link message is then processed by a TX data processor 238, whichalso receives traffic data for a number of data streams from a datasource 236, modulated by a modulator 280, conditioned by transmitters254 a through 254 r, and transmitted back to transmitter system 210.

At transmitter system 210, the modulated signals from receiver system250 are received by antennas 224, conditioned by receivers 222,demodulated by a demodulator 240, and processed by a RX data processor242 to extract the reserve link message transmitted by the receiversystem 250. Processor 230 then determines which pre-coding matrix to usefor determining the beamforming weights then processes the extractedmessage.

Turning to FIG. 3, this figure shows an alternative simplifiedfunctional block diagram of a communication device according to oneembodiment of the invention. As shown in FIG. 3, the communicationdevice 300 in a wireless communication system can be utilized forrealizing the UEs (or ATs) 116 and 122 in FIG. 1 or the base station (orAN) 100 in FIG. 1, and the wireless communications system is preferablythe LTE or NR system. The communication device 300 may include an inputdevice 302, an output device 304, a control circuit 306, a centralprocessing unit (CPU) 308, a memory 310, a program code 312, and atransceiver 314. The control circuit 306 executes the program code 312in the memory 310 through the CPU 308, thereby controlling an operationof the communications device 300. The communications device 300 canreceive signals input by a user through the input device 302, such as akeyboard or keypad, and can output images and sounds through the outputdevice 304, such as a monitor or speakers. The transceiver 314 is usedto receive and transmit wireless signals, delivering received signals tothe control circuit 306, and outputting signals generated by the controlcircuit 306 wirelessly. The communication device 300 in a wirelesscommunication system can also be utilized for realizing the AN 100 inFIG. 1.

FIG. 4 is a simplified block diagram of the program code 312 shown inFIG. 3 in accordance with one embodiment of the invention. In thisembodiment, the program code 312 includes an application layer 400, aLayer 3 portion 402, and a Layer 2 portion 404, and is coupled to aLayer 1 portion 406. The Layer 3 portion 402 generally performs radioresource control. The Layer 2 portion 404 generally performs linkcontrol. The Layer 1 portion 406 generally performs physicalconnections.

3GPP TS 38.885 introduced QoS (Quality of Service) management for NR V2Xsidelink as follows:

7 QoS Management

QoS management is relevant to V2X in the context of its use in resourceallocation, congestion control, in-device coexistence, power control andSLRB configuration. Physical layer parameters related to QoS managementare the priority, latency, reliability and minimum requiredcommunication range (as defined by higher layers) of the traffic beingdelivered. Data rate requirements are also supported in the AS. A SLcongestion metric and, at least in resource allocation mode 2,mechanisms for congestion control are needed. It is beneficial to reportthe SL congestion metric to gNB.

For SL unicast, groupcast and broadcast, QoS parameters of V2X packetsare provided by upper layers to the AS. For SL unicast, the SLRBs are(pre-)configured based on the signalling flows and procedures shown inFIGS. 7-1 and 7-2. The per-flow QoS model described in [6] is assumed inupper layers.

[FIG. 7-1 of 3GPP TS 38.885 V16.0.0, entitled “SLRB configuration for SLunicast (UE-specific)”, is reproduced as FIG. 5]

In Step 0 of FIG. 7-1, the PC5 QoS profile, i.e. a set of specific PC5QoS parameters, and PC5 QoS rule for each PC5 QoS flow are provisionedto the UE in advance by service authorization and provisioningprocedures as in [6]; similarly, PC5 QoS profile for each QoS flow isalso provisioned to the gNB/ng-eNB in advance. Then, when packet(s)arrive, the UE can first derive the identifier of the associated PC5 QoSflow(s) (i.e. PC5 QFI) based on the PC5 QoS rules configured in Step 0,and may then report the derived PC5 QFI(s) to the gNB/ng-eNB in Step 3.The gNB/ng-eNB can derive the QoS profile(s) of these reported PC5QFI(s) based on the provisioning from 5GC in Step 0, and may signal theconfigurations of the SLRB(s) associated with the PC5 QFI(s) UE reportedvia RRC dedicated signalling in Step 4. These SLRB configurations mayinclude PC5 QoS flow to SLRB mapping, SDAP/PDCP/RLC/LCH configurations,etc. In Step 5, the UE in the AS establishes SLRB(s) associated with thePC5 QFI(s) of the packet(s) with the peer UE as per gNB/ng-eNBconfiguration, and maps available packet(s) to the SLRB(s) established.SL unicast transmission can then occur.

NOTE: How the PC5 QFI is defined is up to SA2 WG2.

3GPP TS 36.331 stated:

5.10.2 Sidelink UE Information

5.10.2.1 General

[FIG. 5.10.2-1 of 3GPP TS 36.331 V15.3.0, entitled “Sidelink UEinformation”, is reproduced as FIG. 6]

The purpose of this procedure is to inform E-UTRAN that the UE isinterested or no longer interested to receive sidelink communication ordiscovery, to receive V2X sidelink communication, as well as to requestassignment or release of transmission resources for sidelinkcommunication or discovery announcements or V2X sidelink communicationor sidelink discovery gaps, to report parameters related to sidelinkdiscovery from system information of inter-frequency/PLMN cells and toreport the synchronization reference used by the UE for V2X sidelinkcommunication.

5.10.2.2 Initiation

A UE capable of sidelink communication or V2X sidelink communication orsidelink discovery that is in RRC_CONNECTED may initiate the procedureto indicate it is (interested in) receiving sidelink communication orV2X sidelink communication or sidelink discovery in several casesincluding upon successful connection establishment, upon change ofinterest, upon change to a PCell broadcastingSystemInformationBlockType18 or SystemInformationBlockType19 orSystemInformationBlockType21 including sl-V2X-ConfigCommon. A UE capableof sidelink communication or V2X sidelink communication or sidelinkdiscovery may initiate the procedure to request assignment of dedicatedresources for the concerned sidelink communication transmission ordiscovery announcements or V2X sidelink communication transmission or torequest sidelink discovery gaps for sidelink discovery transmission orsidelink discovery reception and a UE capable of inter-frequency/PLMNsidelink discovery parameter reporting may initiate the procedure toreport parameters related to sidelink discovery from system informationof inter-frequency/PLMN cells.

-   -   NOTE 1: A UE in RRC_IDLE that is configured to transmit sidelink        communication/V2X sidelink communication/sidelink discovery        announcements, while        SystemInformationBlockType18/SystemInformationBlockType19/SystemInformationBlockType21        including sl-V2X-ConfigCommon or SystemInformationBlockType26        does not include the resources for transmission (in normal        conditions), initiates connection establishment in accordance        with 5.3.3.1a.

Upon initiating the procedure, the UE shall:

[ . . . ]

-   -   1> if SystemInformationBlockType21 including sl-V2X-ConfigCommon        is broadcast by the PCell:        -   2> ensure having a valid version of            SystemInformationBlockType21 and            SystemInformationBlockType26, if broadcast, for the PCell;        -   2> if configured by upper layers to receive V2X sidelink            communication on a primary frequency or on one or more            frequencies included in v2x-InterFreqInfoList, if included            in SystemInformationBlockType21 or            SystemInformationBlockType26 of the PCell:            -   3> if the UE did not transmit a SidelinkUEInformation                message since last entering RRC_CONNECTED state; or            -   3> if since the last time the UE transmitted a                SidelinkUEInformation message the UE connected to a                PCell not broadcasting SystemInformationBlockType21                including sl-V2X-ConfigCommon; or            -   3> if the last transmission of the SidelinkUEInformation                message did not include v2x-CommRxInterestedFreqList; or                if the frequency(ies) configured by upper layers to                receive V2X sidelink communication on has changed since                the last transmission of the SidelinkUEInformation                message:                -   4> initiate transmission of the                    SidelinkUEInformation message to indicate the V2X                    sidelink communication reception frequency(ies) of                    interest in accordance with 5.10.2.3;        -   2> else:            -   3> if the last transmission of the SidelinkUEInformation                message included v2x-CommRxInterestedFreqList:                -   4> initiate transmission of the                    SidelinkUEInformation message to indicate it is no                    longer interested in V2X sidelink communication                    reception in accordance with 5.10.2.3;        -   2> if configured by upper layers to transmit V2X sidelink            communication on a primary frequency or on one or more            frequencies included in v2x-InterFreqInfoList, if included            in SystemInformationBlockType21 or            SystemInformationBlockType26 of the PCell:            -   3> if the UE did not transmit a SidelinkUEInformation                message since last entering RRC_CONNECTED state; or            -   3> if since the last time the UE transmitted a                SidelinkUEInformation message the UE connected to a                PCell not broadcasting SystemInformationBlockType21                including sl-V2X-ConfigCommon; or            -   3> if the last transmission of the SidelinkUEInformation                message did not include v2x-CommTxResourceReq; or if the                information carried by the v2x-CommTxResourceReq has                changed since the last transmission of the                SidelinkUEInformation message:                -   4> initiate transmission of the                    SidelinkUEInformation message to indicate the V2X                    sidelink communication transmission resources                    required by the UE in accordance with 5.10.2.3;        -   2> else:            -   3> if the last transmission of the SidelinkUEInformation                message included v2x-CommTxResourceReq:                -   4> initiate transmission of the                    SidelinkUEInformation message to indicate it no                    longer requires V2X sidelink communication                    transmission resources in accordance with 5.10.2.3;                -    SidelinkUEInformation

The SidelinkUEInformation message is used for the indication of sidelinkinformation to the eNB.

-   -   Signalling radio bearer: SRB1    -   RLC-SAP: AM    -   Logical channel: DCCH    -   Direction: UE to E-UTRAN

SidelinkUEInformation Message

-- ASN1START ... SidelinkUEInformation-v1430-IEs ::= SEQUENCE {v2x-CommRxInterestedFreqList-r14 SL-V2X-CommFreqList-r14 OPTIONAL,p2x-CommTxType-r14 ENUMERATED {true} OPTIONAL, v2x-CommTxResourceReq-r14SL-V2X-CommTxFreqList-r14 OPTIONAL, nonCriticalExtensionSidelinkUEInformation-v1530-IEs OPTIONAL }SidelinkUEInformation-v1530-IEs ::= SEQUENCE { reliabilityInfoListSL-r15SL-ReliabilityList-r15 OPTIONAL, nonCriticalExtension SEQUENCE { }OPTIONAL } ... SL-V2X-CommFreqList-r14 ::= SEQUENCE (SIZE(1..maxFreqV2X-r14)) OF INTEGER (0..maxFreqV2X-1-r14)SL-V2X-CommTxFreqList-r14 ::= SEQUENCE (SIZE (1..maxFreqV2X-r14)) OFSL-V2X-CommTxResourceReq- r14 SL-V2X-CommTxResourceReq-r14 ::= SEQUENCE{ carrierFreqCommTx-r14 INTEGER (0.. maxFreqV2X-1-r14) OPTIONAL,v2x-TypeTxSync-r14 SL-TypeTxSync-r14 OPTIONAL,v2x-DestinationInfoList-r14 } SL-DestinationInfoList-r12 OPTIONAL } --ASN1STOP

SidelinkUEInformation field descriptions carrierFreqCommTx Indicates theindex of the frequency on which the UE is interested to transmit V2Xsidelink communication. The value 1 corresponds to the frequency offirst entry in v2x-InterFreqInfoList broadcast in SIB21, the value 2corresponds to the frequency of second entry in v2x-InterFreqInfoListbroadcast in SIB21 and so on. The value 0 corresponds the PCell'sfrequency. commRxInterestedFreq Indicates the frequency on which the UEis interested to receive sidelink communication. commTxResourceReqIndicates the frequency on which the UE is interested to transmitnon-relay related sidelink communication as well as the one-to-manysidelink communication transmission destination(s) for which the UErequests E-UTRAN to assign dedicated resources. NOTE 1.reliabilityInfoListSL Indicates the reliability(ies) (i.e., PPPRs [9])associated with the reported traffic to be transmitted for V2X sidelinkcommunication. v2x-CommRxInterestedFreqList Indicates the index(es) ofthe frequency(ies) on which the UE is interested to receive V2X sidelinkcommunication. The value 1 corresponds to the frequency of first entryin v2x-InterFreqInfoList broadcast in SIB21, the value 2 corresponds tothe frequency of second entry in v2x-InterFreqInfoList broadcast inSIB21 and so on. The value 0 corresponds the PCell's frequency.carrierFreqCommTx Indicates the index of the frequency on which the UEis interested to transmit V2X sidelink communication. The value 1corresponds to the frequency of first entry in v2x-InterFreqInfoListbroadcast in SIB21, the value 2 corresponds to the frequency of secondentry in v2x-InterFreqInfoList broadcast in SIB21 and so on. The value 0corresponds the PCell's frequency. v2x-DestinationInfoList Indicates thedestination(s) for V2X sidelink communication. v2x-TypeTxSync Indicatesthe synchronization reference used by the UE.

3GPP TS 23.287 stated:

5.2.1.4 Unicast Mode Communication Over PC5 Reference Point

Unicast mode of communication is only supported over NR based PC5reference point. FIG. 5.2.1.4-1 illustrates an example of PC5 unicastlinks.

[FIG. 5.2.1.4-1 of 3GPP TR 23.786 V1.0.0, entitled “Example of PC5Unicast Links”, is reproduced as FIG. 7]

The following principles apply when the V2X communication is carriedover PC5 unicast link:

-   -   A PC5 unicast link between two UEs allows V2X communication        between one or more pairs of peer V2X services in these UEs. All        V2X services in the UE using the same PC5 unicast link use the        same Application Layer ID.    -   NOTE 1: An Application Layer ID may change in time as described        in clauses 5.6.1.1 and 6.3.3.2, due to privacy. This does not        cause a re-establishment of a PC5 unicast link.    -   One PC5 unicast link supports one or more V2X services (e.g.        PSIDs or ITS-AIDS) if these V2X services are at least associated        with the pair of peer Application Layer IDs for this PC5 unicast        link. For example, as illustrated in FIG. 5.2.1.4-1, UE A and UE        B have two PC5 unicast links, one between peer Application Layer        ID 1/UE A and Application Layer ID 2/UE B and one between peer        Application Layer ID 3/UE A and Application Layer ID 4/UE B.    -   NOTE 2: A source UE is not required to know whether different        target Application Layer IDs over different PC5 unicast links        belong to the same target UE.        -   A PC5 unicast link supports V2X communication using a single            network layer protocol e.g. IP or non-IP.        -   A PC5 unicast link supports per-flow QoS model as specified            in clause 5.4.1.

When the Application layer in the UE initiates data transfer for a V2Xservice which requires unicast mode of communication over PC5 referencepoint:

-   -   the UE shall reuse an existing PC5 unicast link if the pair of        peer Application Layer IDs and the network layer protocol of        this PC5 unicast link are identical to those required by the        application layer in the UE for this V2X service, and modify the        existing PC5 unicast link to add this V2X service as specified        in clause 6.3.3.4; otherwise    -   the UE shall trigger the establishment of a new PC5 unicast link        as specified in clause 6.3.3.1.

After successful PC5 unicast link establishment, UE A and UE B use thesame pair of Layer-2 IDs for subsequent PC5-S signalling messageexchange and V2X service data transmission as specified in clause5.6.1.4. The V2X layer of the transmitting UE indicates to the AS layerwhether a transmission is for a PC5-S signalling message (i.e. DirectCommunication Request/Accept, Link Identifier Update Request/Response,Disconnect Request/Response, Link Modification Request/Accept) or V2Xservice data.

For every PC5 unicast link, a UE self-assigns a distinct PC5 LinkIdentifier that uniquely identifies the PC5 unicast link in the UE forthe lifetime of the PC5 unicast link. Each PC5 unicast link isassociated with a Unicast Link Profile which includes:

-   -   service type(s) (e.g. PSID or ITS-AID), Application Layer ID and        Layer-2 ID of UE A; and    -   Application Layer ID and Layer-2 ID of UE B; and    -   network layer protocol used on the PC5 unicast link; and    -   for each V2X service, a set of PC5 QoS Flow Identifier(s)        (PFI(s)). Each PFI is associated with QoS parameters (i.e. PQI        and optionally Range).

For privacy reason, the Application Layer IDs and Layer-2 IDs may changeas described in clauses 5.6.1.1 and 6.3.3.2 during the lifetime of thePC5 unicast link and, if so, shall be updated in the Unicast LinkProfile accordingly. The UE uses PC5 Link Identifier to indicate the PC5unicast link to V2X Application layer, therefore V2X Application layeridentifies the corresponding PC5 unicast link even if there are morethan one unicast link associated with one service type (e.g. the UEestablishes multiple unicast links with multiple UEs for a same servicetype).

The Unicast Link Profile shall be updated accordingly after a Layer-2link modification for an established PC5 unicast link as specified inclause 6.3.3.4.

[ . . . ]

5.4.1 QoS Handling for V2X Communication Over PC5 Reference Point

5.4.1.1 QoS Model

5.4.1.1.1 General Overview

For LTE based PC5, the QoS handling is defined in TS 23.285 [8], basedon ProSe Per-Packet Priority (PPPP) and ProSe Per-Packet Reliability(PPPR).

For NR based PC5, a QoS model similar to that defined in TS 23.501 [6]for Uu reference point is used, i.e. based on 5QIs, with additionalparameter of Range. For the V2X communication over NR based PC5reference point, a PC5 QoS Flow is associated with a PC5 QoS Rule thatcontains the PC5 QoS parameters as defined in clause 5.4.2. A set ofstandardized PC5 5QIs (PQI) are defined in clause 5.4.4. The UE may beconfigured with a set of default PC5 QoS parameters to use for the V2Xservices, as defined in clause 5.1.2.1. For NR based unicast, groupcastand broadcast PC5 communication, Per-flow QoS model for PC5 QoSmanagement shall be applied. FIG. 5.4.1.1.1-1 illustrates an examplemapping of Per-flow QoS model for NR PC5. Details of PC5 QoS Rules andPFI related operations are described in clauses 5.4.1.1.2 and 5.4.1.1.3.

[FIG. 5.4.1.1.1-1 of 3GPP TR 23.786 V1.0.0, entitled “Per-Flow PC5 QoSModel for NR PC5”, is reproduced as FIG. 8]

The following principles apply when the V2X communication is carriedover PC5 reference point:

-   -   Application layer may set the V2X Application Requirements for        the V2X communication, using either TS 23.285 [8] defined PPPP        and PPPR model or the PQI and Range model. Depends on the type        of PC5 reference point, i.e. LTE based or NR based, selected for        the transmission, the UE may map the application layer provided        V2X Application Requirements to the suitable QoS parameters to        be passed to the lower layer. The mapping between the two QoS        models is defined in clause 5.4.2. For V2X communication over NR        based PC5, different V2X packets may require different QoS        treatments. In that case, the V2X packets shall be sent from the        V2X layer to the Access Stratum layer within PC5 QoS Flows        identified by different PFIs.    -   When groupcast mode of V2X communication over NR based PC5 is        used, a Range parameter is associated with the QoS parameters        for the V2X communication. The Range may be provided by V2X        application layer or use a default value mapped from the service        type based on configuration as defined in clause 5.1.2.1. The        Range indicates the minimum distance that the QoS parameters        need to be fulfilled. The Range parameter is passed to AS layer        together with the QoS parameters for dynamic control.    -   NR based PC5 supports three types of communication mode, i.e.        broadcast, groupcast, and unicast. The QoS handling of these        different modes are described in clauses 5.4.1.2 to 5.4.1.4.    -   The UE may handle broadcast, groupcast, and unicast traffic by        taking all their priorities, e.g. indicated by PQIs, into        account.    -   For broadcast and groupcast modes of V2X communication over NR        based PC5, standardized PQI values are applied by the UE, as        there is no signalling over PC5 reference point for these cases.    -   When network scheduled operation mode is used, the UE-PC5-AMBR        for NR based PC5 applies to all types of communication modes,        and is used by NG-RAN for capping the UE's NR based PC5        transmission in the resources management.        5.4.1.1.2 Deriving PC5 QoS Parameters and Assigning PFI for PC5        QoS Flow

The following description applies to for both network scheduledoperation mode and UE autonomous resources selection mode.

When service data or request from the V2X application layer is received,the UE determines if there is any existing PC5 QoS Flow matching theservice data or request, i.e. based on the PC5 QoS Rules for theexisting PC5 QoS Flow(s).

If there is no PC5 QoS Flow matching the service data or request, the UEderives PC5 QoS parameters based on the V2X Application Requirementsprovided by the V2X application layer (if available) and the V2X servicetype (e.g. PSID or ITS-AID) according to the PC5 QoS mappingconfiguration defined in clause 5.1.2.1. The UE creates a new PC5 QoSFlow for the derived PC5 QoS parameters.

The UE then assigns a PFI and derives PC5 QoS Rule for this PC5 QoSFlow.

For V2X communication over NR PC5 reference point, the PC5 QoS Flow isthe finest granularity of QoS differentiation in the same destinationidentified by Destination Layer-2 ID. User Plane traffic with the samePFI receives the same traffic forwarding treatment (e.g. scheduling,admission threshold). The PFI is unique within a same destination.

-   -   Editor's note: It is FFS whether to handle same PC5 QoS        parameters with same destination L2 ID for a V2X service using        different communication modes (e.g. broadcast, groupcast,        unicast) as separate PC5 QoS Flows.        5.4.1.1.3 Handling of PC5 QoS Flows Based on PC5 QoS Rules

For each communication mode (e.g. broadcast, groupcast, unicast), the UEmaintains the mappings of PFIs to the PC5 QoS Context and PC5 QoS Rulesper destination identified by Destination Layer-2 ID. A PC5 QoS Contextincludes PC5 QoS parameters (e.g. PQI and Range) and the V2X servicetype (e.g. PSID or ITS-AID). When the UE assigns a new PFI for V2Xservice, the UE stores it with the corresponding PC5 QoS Context and PC5QoS Rules for the destination. When the UE releases the PFI, the UEremoves the corresponding PC5 QoS Context and PC5 QoS Rules for thedestination. For unicast, the Unicast Link Profile defined in clause5.2.1.4 contains addition information mapped from PFI for unicastoperation.

The PC5 QoS Rule contains the PFI of the associated PC5 QoS Flow, aprecedence value, and a PC5 Packet Filter Set as defined in clause5.4.1.1.4. The precedence value determines the order in which the PC5QoS Rules are evaluated. The PC5 QoS Rule with lower precedence value isevaluated before those with the higher precedence values.

The V2X layer provides information for PC5 QoS operations perdestination (e.g. identified by Destination Layer-2 ID) to AS layer forPer-flow QoS model operations as below:

-   -   1) To add a new PC5 QoS Flow or to modify any existing PC5 QoS        Flow, the V2X layer provides the PFI, the corresponding PC5 QoS        parameters and source/destination Layer-2 IDs for the PC5 QoS        Flow to AS layer.    -   2) To remove any existing PC5 QoS Flow, the V2X layer provides        the PFI and source/destination Layer-2 IDs for the PC5 QoS Flow        to AS layer.    -   NOTE: 1) and 2) apply to broadcast and groupcast.

In addition, the V2X layer also provides the communication mode (e.g.broadcast, groupcast, unicast), radio frequencies, Tx Profile to the ASlayer for the PC5 operation. The radio frequencies and Tx Profile aredetermined based on the V2X service type. The V2X layer ensures that V2Xservices (e.g. identified by PSID or ITS-AID) associated with differentradio frequencies are classified into distinct PC5 QoS Flows.

FIG. 5.4.1.1.3-1 illustrated an example of the classification andmarking of user plane traffic using the PC5 QoS Rules, and the mappingof PC5 QoS Flows to radio resources at access stratum layer.

[FIG. 5.4.1.1.3-1 of 3GPP TR 23.786 V1.0.0, entitled “Handling of PC5QoS Flows based on PC5 QoS Rules”, is reproduced as FIG. 9]

As illustrated in FIG. 5.4.1.1.3-1, for a given pair of source anddestination Layer-2 IDs, there can be multiple radio bearers, eachcorresponding to a different PC5 QoS level. The AS layer can determinethe mapping of multiple PC5 QoS Flows to the same radio bearer based onthe information provided. For broadcast and groupcast, the L2 link goesto all UEs in proximity identified by the destination Layer-2 ID.

6.1.1 User Plane for NR PC5 Reference Point Supporting V2X Services

[FIG. 6.1.1-1 of 3GPP TR 23.786 V1.0.0, entitled “User Plane for PC5interface”, is reproduced as FIG. 10]

IP and Non-IP PDCP SDU types are supported for the V2X communicationover PC5.

For IP PDCP SDU type, only IPv6 is supported. The IP address allocationand configuration are as defined in clause 5.6.1.1.

The Non-IP PDCP SDU contains a Non-IP Type header, which indicates theV2X message family used by the application layer, e.g. IEEE 1609family's WSMP [18], ISO defined FNTP [19].

NOTE: The Non-IP Type header and allowed values will be defined in stage3 specification.

[ . . . ]

6.3.3 Unicast Mode V2X Communication Over PC5 Reference Point

6.3.3.1 Layer-2 Link Establishment Over PC5 Reference Point

To perform unicast mode of V2X communication over PC5 reference point,the UE is configured with the related information as described in clause5.1.2.1.

FIG. 6.3.3.1-1 shows the layer-2 link establishment procedure forunicast mode of V2X communication over PC5 reference point.

[FIG. 6.3.3.1-1 of 3GPP TR 23.786 V1.0.0, entitled “Layer-2 linkestablishment procedure”, is reproduced as FIG. 11]

-   -   1. The UE(s) determine the destination Layer-2 ID for signalling        reception for PC5 unicast link establishment as specified in        clause 5.6.1.4. The destination Layer-2 ID is configured with        the UE(s) as specified in clause 5.1.2.1.    -   2. The V2X application layer in UE-1 provides application        information for PC5 unicast communication. The application        information includes the service type(s) (e.g. PSID or ITS-AID)        of the V2X application and the initiating UE's Application Layer        ID. The target UE's Application Layer ID may be included in the        application information.        -   The V2X application layer in UE-1 may provide V2X            Application Requirements for this unicast communication.            UE-1 determines the PC5 QoS parameters and PFI as specified            in clause 5.4.1.4.        -   If UE-1 decides to reuse the existing PC5 unicast link as            specified in clause 5.2.1.4, the UE triggers Layer-2 link            modification procedure as specified in clause 6.3.3.4.    -   3. UE-1 sends a Direct Communication Request message to initiate        the unicast layer-2 link establishment procedure. The Direct        Communication Request message includes:        -   Source User Info: the initiating UE's Application Layer ID            (i.e. UE-Vs Application Layer ID).        -   If the V2X application layer provided the target UE's            Application Layer ID in step 2, the following information is            included:            -   Target User Info: the target UE's Application Layer ID                (i.e. UE-2's Application Layer ID).        -   V2X Service Info: the information about V2X Service(s)            requesting Layer-2 link establishment (e.g. PSID(s) or            ITS-AID(s)).        -   Indication whether IP communication is used.        -   IP Address Configuration: For IP communication, IP address            configuration is required for this link and indicates one of            the following values:            -   “IPv6 Router” if IPv6 address allocation mechanism is                supported by the initiating UE, i.e., acting as an IPv6                Router; or            -   “IPv6 address allocation not supported” if IPv6 address                allocation mechanism is not supported by the initiating                UE.        -   Link Local IPv6 Address: a link-local IPv6 address formed            locally based on RFC 4862 [21] if UE-1 does not support the            IPv6 IP address allocation mechanism, i.e. the IP Address            Configuration indicates “IPv6 address allocation not            supported”.        -   QoS Info: the information about PC5 QoS Flow(s). For each            PC5 QoS Flow, the PFI and the corresponding PC5 QoS            parameters (i.e. PQI and conditionally other parameters such            as MFBR/GFBR, etc).    -   The source Layer-2 ID and destination Layer-2 ID used to send        the Direct Communication Request message are determined as        specified in clauses 5.6.1.1 and 5.6.1.4.    -   UE-1 sends the Direct Communication Request message via PC5        broadcast using the source Layer-2 ID and the destination        Layer-2 ID.    -   4. A Direct Communication Accept message is sent to UE-1 as        below:        -   4a. (UE oriented Layer-2 link establishment) If the Target            User Info is included in the Direct Communication Request            message, the target UE, i.e. UE-2 responds with a Direct            Communication Accept message.        -   4b. (V2X Service oriented Layer-2 link establishment) If the            Target User Info is not included in the Direct Communication            Request message, the UEs that are interested in using the            announced V2X Service(s), so decide to establish Layer-2            link with UE-1 respond to the request by sending a Direct            Communication Accept message (UE-2 and UE-4 in FIG.            6.3.3.1-1).        -   The Direct Communication Accept message includes:            -   Source User Info: Application Layer ID of the UE sending                the Direct Communication Accept message.            -   QoS Info: the information about PC5 QoS Flow(s). For                each PC5 QoS Flow, the PFI and the corresponding PC5 QoS                parameters requested by UE-1 (i.e. PQI and conditionally                other parameters such as MFBR/GFBR, etc).            -   IP Address Configuration: For IP communication, IP                address configuration is required for this link and                indicates one of the following values:                -   “IPv6 Router” if IPv6 address allocation mechanism                    is supported by the target UE, i.e., acting as an                    IPv6 Router; or                -   “IPv6 address allocation not supported” if IPv6                    address allocation mechanism is not supported by the                    target UE.            -   Link Local IPv6 Address: a link-local IPv6 address                formed locally based on RFC 4862 [21] if the target UE                does not support the IPv6 IP address allocation                mechanism, i.e. the IP Address Configuration indicates                “IPv6 address allocation not supported”, and UE-1                included a link-local IPv6 address in the Direct                Communication Request message. The target UE shall                include a non-conflicting link-local IPv6 address.        -   If both UEs (i.e. the initiating UE and the target UE)            selected to use link-local IPv6 address, they shall disable            the duplicate address detection defined in RFC 4862 [21].    -   NOTE 1: When either the initiating UE or the target UE indicates        the support of IPv6 router, corresponding address configuration        procedure would be carried out after the establishment of the        layer 2 link, and the link-local IPv6 addresses are ignored.        -   The source Layer-2 ID used to send the Direct Communication            Accept message is determined as specified in clauses 5.6.1.1            and 5.6.1.4. The destination Layer-2 ID is set to the source            Layer-2 ID of the received Direct Communication Request            message.        -   Upon receiving the Direct Communication Accept message from            peer UE, UE-1 obtains the peer UE's Layer-2 ID for future            communication, for signalling and data traffic for this            unicast link.        -   The V2X layer of the UE that established PC5 unicast link            passes the PC5 Link Identifier assigned for the unicast link            and PC5 unicast link related information down to the AS            layer. The PC5 unicast link related information includes            Layer-2 ID information (i.e. source Layer-2 ID and            destination Layer-2 ID). This enables the AS layer to            maintain the PC5 Link Identifier together with the PC5            unicast link related information.    -   Editor's Note: Steps for mutual authentication and security        association establishment will be determined based on feedback        from SA WG3.    -   5. V2X service data is transmitted over the established unicast        link as below:        -   The PC5 Link Identifier and PFI are provided to the AS            layer, together with the V2X service data.        -   UE-1 sends the V2X service data using the source Layer-2 ID            (i.e. UE-1's Layer-2 ID for this unicast link) and the            destination Layer-2 ID (i.e. the peer UE's Layer-2 ID for            this unicast link).    -   NOTE 2: PC5 unicast link is bi-directional, therefore the peer        UE of UE-1 can send the V2X service data to UE-1 over the        unicast link with UE-1.    -   Editor's Note: The parameters included in the Direct        Communication Request/Accept messages can be updated depending        on RAN WGs' decision on how the Direct Communication        Request/Accept messages are sent by the AS layer (e.g. by using        PC5-RRC signalling).    -   Editor's Note: Additional parameters included in the Direct        Communication Request/Accept messages (e.g. security related)        are FFS.    -   Editor's Note: Whether the unicast communication requires        security protection at link layer will be determined based on        feedback from SA WG3.        6.3.3.3 Layer-2 Link Release Over PC5 Reference Point

FIG. 6.3.3.3-1 shows the layer-2 link release procedure over PC5reference point.

[FIG. 6.3.3.3-1 of 3GPP TR 23.786 V1.0.0, entitled “Layer-2 link releaseprocedure”, is reproduced as FIG. 12]

-   -   0. UE-1 and UE-2 have a unicast link established as described in        clause 6.3.3.1.    -   1. UE-1 sends a Disconnect Request message to UE-2 in order to        release the layer-2 link and deletes all context data associated        with the layer-2 link.    -   2. Upon reception of the Disconnect Request message UE-2 may        respond with a Disconnect Response message and deletes all        context data associated with the layer-2 link.        -   The V2X layer of each UE informs the AS layer that the            unicast link has been released. This enables the AS layer to            delete the context related to the released unicast link.            6.3.3.4 Layer-2 Link Modification for a Unicast Link

FIG. 6.3.3.4-1 shows the layer-2 link modification procedure for aunicast link. This procedure is used to:

-   -   add new V2X service(s) to the existing PC5 unicast link.    -   remove any V2X service(s) from the existing PC5 unicast link.    -   modify any PC5 QoS Flow(s) in the existing PC5 unicast link.

[FIG. 6.3.3.4-1 of 3GPP TR 23.786 V1.0.0, entitled “Layer-2 linkmodification procedure”, is reproduced as FIG. 13]

-   -   0. UE-1 and UE-2 have a unicast link established as described in        clause 6.3.3.1.    -   1. The V2X application layer in UE-1 provides application        information for PC5 unicast communication. The application        information includes the service type(s) (e.g. PSID or ITS-AID)        of the V2X application(s) and the initiating UE's Application        Layer ID. The target UE's Application Layer ID may be included        in the application information. If UE-1 decides to reuse the        existing PC5 unicast link as specified in clause 5.2.1.4, so        decides to modify the unicast link established with UE-2, UE-1        sends a Link Modification Request to UE-2.        -   The Link Modification Request message includes:            -   a) To add new V2X service(s) to the existing PC5 unicast                link:                -   V2X Service Info: the information about V2X                    Service(s) to be added (e.g. PSID(s) or ITS-AID(s)).                -   QoS Info: the information about PC5 QoS Flow(s) for                    each V2X Service to be added. For each PC5 QoS Flow,                    the PFI and the corresponding PC5 QoS parameters                    (i.e. PQI and conditionally other parameters such as                    MFBR/GFBR, etc).            -   b) To remove any V2X service(s) from the existing PC5                unicast link:                -   V2X Service Info: the information about V2X                    Service(s) to be removed (e.g. PSID(s) or                    ITS-AID(s)).            -   c) To modify any PC5 QoS Flow(s) in the existing PC5                unicast link:                -   QoS Info: the information about PC5 QoS Flow(s) to                    be modified. For each PC5 QoS Flow, the PFI and the                    corresponding PC5 QoS parameters (i.e. PQI and                    conditionally other parameters such as MFBR/GFBR,                    etc).    -   2. UE-2 responds with a Link Modification Accept message.        -   The Link Modification Accept message includes:            -   For case a) and case c) described in step 1:                -   QoS Info: the information about PC5 QoS Flow(s). For                    each PC5 QoS Flow, the PFI and the corresponding PC5                    QoS parameters (i.e. PQI and conditionally other                    parameters such as MFBR/GFBR, etc).        -   The V2X layer of each UE provides information about the            unicast link modification to the AS layer. This enables the            AS layer to update the context related to the modified            unicast link.

3GPP RAN2 #106 made following agreements:

Agreements on NR SL QoS and SLRB configurations: 1: Stick to SI phaseconclusion that SLRB configurations should be NW-configured and/orpre-configured for NR SL. 2: For an RRC_CONNECTED UE, for transmissionof a new PC5 QoS flow, it may report the QoS information of the PC5 QoSflow via RRC dedicated signalling to the gNB/ng-eNB. FFS on the exacttiming about when UE initiates. 3: For an RRC_CONNECTED UE, thegNB/ng-eNB may provide SLRB configurations and configure the mapping ofPC5 QoS flow to SLRB via RRC dedicated signalling, based on the QoSinformation reported by the UE. The UE can establishes/reconfigures theSLRB only after receiving the SLRB configuration. FFS when the UEestablishes/reconfigures the SLRB. 4: FFS what the reported QoSinformation is (e.g. PFI, PC5 QoS profile, etc.) and what is used torealize the PC5 QoS flow to SLRB mapping (e.g. PFI to SLRB mapping, QoSprofile to SLRB mapping, etc.), depending on SA2 conclusion on how PFIis assigned. 5: For RRC_IDLE/INACTIVE UEs, the gNB/ng-eNB may provideSLRB configurations and configure the PC5 QoS profile to SLRB mappingvia V2X-specific SIB. When an RRC_IDLE/INACTIVE UE initiates thetransmission of a new PC5 QoS flow, it establishes the SLRB associatedwith the PC5 QoS profile of that flow based on SIB configuration. 6: FFShow to describe each PC5 QoS profile in the SIB, pending SA2's finalconclusion on what PC5 QoS parameters are included in a PC5 QoS profile.7: For OoC UEs, SLRB configurations and the mapping of PC5 QoS profileto SLRB are pre-configured. When an OoC UE initiates the transmission ofa new PC5 QoS flow, it establishes the SLRB associated with the flowbased on pre- configuration. 8: FFS what is used to realize for PC5 QoSflow to SLRB mapping in pre- configuration (e.g. PFI to SLRB mapping,QoS profile to SLRB mapping, etc.), depending on SA2 conclusion on howPFI is assigned. 9: For SL unicast of a UE, theNW-configured/pre-configured SLRBs configurations include the SLRBparameters that are only related to TX, as well as the SLRB parametersthat are related to both TX and RX and need to be aligned with the peerUEs. 10:  For SL unicast, the initiating UE informs the peer UE of SLRBparameters that are related to both TX and RX and need to be alignedwith the peer UEs. FFS on the detailed parameters. 11:  For SL unicast,do not allow a UE to configure “SLRB parameters only related to TX” forthe peer UE in SL via PC5 RRC message. FFS how to handle SRLB parametersonly related to RX. 12:  For SL groupcast and/or broadcast, theNW-configured/preconfigured SLRBs include the SLRB parameters that areonly related to TX. 13:  Those SLRB parameters which are related to bothTX and RX and thus need to be aligned between a UE and all its peerUE(s) should be fixed in the Spec for SL groupcast and broadcast. 14: For SL broadcast, how to set SLRB parameters only related to RX is up toUE implementation. FFS for groupcast case. 15:  SLRB configurationsshould be (pre-)configured for SL unicast, groupcast/broadcastseparately (e.g. SLRB-ConfigForUnicast, SLRB- ConfigForGroupcast,SLRB-ConfigForBroadcast). FFS on the need of separate SLRBconfigurations between groupcast and broadcast.

3GPP TS 37.324 stated:

6.2.2.3 UL Data PDU with SDAP Header

FIG. 6.2.2.3-1 shows the format of SDAP Data PDU of UL with SDAP headerbeing configured.

[FIG. 6.2.2.3-1 of 3GPP TS 37.324 V15.1.0, entitled “UL SDAP Data PDUformat with SDAP header”, is reproduced as FIG. 14]

[ . . . ]

6.3.4 QFI

Length: 6 bits

The QFI field indicates the ID of the QoS flow (3GPP TS 23.501 [4]) towhich the SDAP PDU belongs.

3GPP TS 38.331 stated:

5.3.5.3 Reception of an RRCReconfiguration by the UE

The UE shall perform the following actions upon reception of theRRCReconfiguration:

[ . . . ]

-   -   1> if the RRCReconfiguration message includes the        radioBearerConfig:        -   2> perform the radio bearer configuration according to            5.3.5.6;            [ . . . ]            5.3.5.6 Radio Bearer Configuration            5.3.5.6.1 General

The UE shall perform the following actions based on a receivedRadioBearerConfig IE:

-   -   [ . . . ]        -   1> if the RadioBearerConfig includes the drb-ToReleaseList:            -   2> perform DRB release as specified in 5.3.5.6.4;        -   1> if the RadioBearerConfig includes the drb-ToAddModList:            -   2> perform DRB addition or reconfiguration as specified                in 5.3.5.6.5.                [ . . . ]                5.3.5.6.4 DRB Release

The UE shall:

-   -   1> for each drb-Identity value included in the drb-ToReleaseList        that is part of the current UE configuration; or    -   1> for each drb-Identity value that is to be released as the        result of full configuration according to 5.3.5.11:        -   2> release the PDCP entity and the drb-Identity;        -   2> if SDAP entity associated with this DRB is configured:            -   3> indicate the release of the DRB to SDAP entity                associated with this DRB (TS 37.324 [24], clause 5.3.3);        -   2> if the DRB is associated with an eps-Beareridentity:            -   3> if a new bearer is not added either with NR or E-UTRA                with same eps-Beareridentity:                -   4> indicate the release of the DRB and the                    eps-Beareridentity of the released DRB to upper                    layers.    -   NOTE 1: The UE does not consider the message as erroneous if the        drb-ToReleaseList includes any drb-Identity value that is not        part of the current UE configuration.    -   NOTE 2: Whether or not the RLC and MAC entities associated with        this PDCP entity are reset or released is determined by the        CellGroupConfig.        5.3.5.6.5 DRB Addition/Modification

The UE shall:

-   -   1> for each drb-Identity value included in the drb-ToAddModList        that is not part of the current UE configuration (DRB        establishment including the case when full configuration option        is used):        -   2> establish a PDCP entity and configure it in accordance            with the received pdcp-Config;        -   2> if the PDCP entity of this DRB is not configured with            cipheringDisabled:            -   3> if target RAT of handover is E-UTRA/5GC; or            -   3> if the UE is connected to E-UTRA/5GC:                -   4> if the UE is capable of E-UTRA/5GC but not                    capable of NGEN-DC:                -    5> configure the PDCP entity with the ciphering                    algorithm and K_(UPenc) key configured/derived as                    specified in TS 36.331 [10];                -   4> else (i.e., a UE capable of NGEN-DC):                -    5> configure the PDCP entity with the security                    algorithms according to securityConfig and apply the                    keys (K_(UPenc) and K_(UPint)) associated with the                    master key (K_(eNB)) or secondary key (S-K_(gNB)) as                    indicated in keyToUse, if applicable;            -   3> else (i.e., UE connected to NR or UE in EN-DC):                -   4> configure the PDCP entity with the ciphering                    algorithms according to securityConfig and apply the                    K_(UPenc) key associated with the master key                    (K_(eNB)/K_(gNB)) or the secondary key                    (S-K_(gNB)/S-K_(eNB)) as indicated in keyToUse;        -   2> if the PDCP entity of this DRB is configured with            integrityProtection:            -   3> configure the PDCP entity with the integrity                protection algorithms according to securityConfig and                apply the K_(UPint) key associated with the master                (K_(eNB)/K_(gNB)) or the secondary key                (S-K_(gNB)/S-K_(eNB)) as indicated in keyToUse;        -   2> if an sdap-Config is included:            -   3> if an SDAP entity with the received pdu-Session does                not exist:                -   4> establish an SDAP entity as specified in TS                    37.324 [24] clause 5.1.1;                -   4> if an SDAP entity with the received pdu-Session                    did not exist prior to receiving this                    reconfiguration:                -    5> indicate the establishment of the user plane                    resources for the pdu-Session to upper layers;            -   3> configure the SDAP entity in accordance with the                received sdap-Config as specified in TS 37.324 [24] and                associate the DRB with the SDAP entity;        -   2> if the DRB is associated with an eps-Beareridentity:            -   3> if the DRB was configured with the same                eps-Beareridentity either by NR or E-UTRA prior to                receiving this reconfiguration:                -   4> associate the established DRB with the                    corresponding eps-Beareridentity;            -   3> else:                -   4> indicate the establishment of the DRB(s) and the                    eps-Beareridentity of the established DRB(s) to                    upper layers;    -   1> for each drb-Identity value included in the drb-ToAddModList        that is part of the current UE configuration:        -   2> if the reestablishPDCP is set:            -   3> if target RAT of handover is E-UTRA/5GC; or            -   3> if the UE is connected to E-UTRA/5GC:                -   4> if the UE is capable of E-UTRA/5GC but not                    capable of NGEN-DC:                -    5> if the PDCP entity of this DRB is not configured                    with cipheringDisabled:                -    6> configure the PDCP entity with the ciphering                    algorithm and K_(upenc) key configured/derived as                    specified in TS 36.331 [10], clause 5.4.2.3, i.e.                    the ciphering configuration shall be applied to all                    subsequent PDCP PDUs received and sent by the UE;                -   4> else (i.e., a UE capable of NGEN-DC):                -    5> if the PDCP entity of this DRB is not configured                    with cipheringDisabled:                -    6> configure the PDCP entity with the ciphering                    algorithm and K_(upenc) key associated with the                    master key (K_(eNB)) or the secondary key                    (S-K_(gNB)), as indicated in keyToUse, i.e. the                    ciphering configuration shall be applied to all                    subsequent PDCP PDUs received and sent by the UE;            -   3> else (i.e., UE connected to NR or UE in EN-DC):                -   4> if the PDCP entity of this DRB is not configured                    with cipheringDisabled:                -    5> configure the PDCP entity with the ciphering                    algorithm and K_(UPenc) key associated with the                    master key (K_(eNB)/K_(gNB)) or the secondary key                    (S-K_(gNB)/S-K_(eNB)), as indicated in keyToUse,                    i.e. the ciphering configuration shall be applied to                    all subsequent PDCP PDUs received and sent by the                    UE;                -   4> if the PDCP entity of this DRB is configured with                    integrityProtection:                -    5> configure the PDCP entity with the integrity                    protection algorithms according to securityConfig                    and apply the K_(UPint) key associated with the                    master key (K_(eNB)/K_(gNB)) or the secondary key                    (S-K_(gNB)/S-K_(eNB)) as indicated in keyToUse;            -   3> if drb-ContinueROHC is included in pdcp-Config:                -   4> indicate to lower layer that drb-ContinueROHC is                    configured;            -   3> re-establish the PDCP entity of this DRB as specified                in TS 38.323 [5], clause 5.1.2;        -   2> else, if the recoverPDCP is set:            -   3> trigger the PDCP entity of this DRB to perform data                recovery as specified in TS 38.323 [5];        -   2> if the pdcp-Config is included:            -   3> reconfigure the PDCP entity in accordance with the                received pdcp-Config.        -   2> if the sdap-Config is included:            -   3> reconfigure the SDAP entity in accordance with the                received sdap-Config as specified in TS37.324 [24];            -   3> for each QFI value added in mappedQoS-FlowsToAdd, if                the QFI value is previously configured, the QFI value is                released from the old DRB;    -   NOTE 1: Void.    -   NOTE 2: When determining whether a drb-Identity value is part of        the current UE configuration, the UE does not distinguish which        RadioBearerConfig and DRB-ToAddModList that DRB was originally        configured in. To re-associate a DRB with a different key        (K_(eNB) to S-K_(gNB) or vice versa), the network provides the        drb-Identity value in the (target) drb-ToAddModList and sets the        reestablishPDCP flag. The network does not list the drb-Identity        in the (source) drb-ToReleaseList.    -   NOTE 3: When setting the reestablishPDCP flag for a radio        bearer, the network ensures that the RLC receiver entities do        not deliver old PDCP PDUs to the re-established PDCP entity. It        does that e.g. by triggering a reconfiguration with sync of the        cell group hosting the old RLC entity or by releasing the old        RLC entity.    -   NOTE 4: In this specification, UE configuration refers to the        parameters configured by NR RRC unless otherwise stated.    -   NOTE 5: Ciphering and integrity protection can be enabled or        disabled for a DRB. The enabling/disabling of ciphering or        integrity protection can be changed only by releasing and adding        the DRB.        [ . . . ]

SDAP-Config

The IE SDAP-Config is used to set the configurable SDAP parameters for adata radio bearer. All configured instances of SDAP-Config with the samevalue of pdu-Session correspond to the same SDAP entity as specified inTS 37.324 [24].

SDAP-Config Information Element

-- ASN1START -- TAG-SDAP-CONFIG-START SDAP-Config ::= SEQUENCE {pdu-Session PDU-SessionID, sdap-HeaderDL ENUMERATED {present, absent},sdap-HeaderUL ENUMERATED {present, absent}, defaultDRB BOOLEAN,mappedQoS-FlowsToAdd SEQUENCE (SIZE (1..maxNrofQFIs}} OF QFI OPTIONAL,-- Need N mappedQoS-FlowsToRelease SEQUENCE (SIZE (1..maxNrofQFIs}} OFQFI OPTIONAL, -- Need N ... } QFI ::= INTEGER (0..maxQFI) PDU-SessionID::= INTEGER (0..255) -- TAG-SDAP-CONFIG-STOP -- ASN1STOP

SDAP-Config field descriptions defaultDRB Indicates whether or not thisis the default DRB for this PDU session. Among all configured instancesof SDAP-Config with the same value of pdu-Session, this field shall beset to true in at most one instance of SDAP-Config and to false in allother instances. mappedQoS-FlowsToAdd Indicates the list of QFIs of ULQoS flows of the PDU session to be additionally mapped to this DRB. AQFI value can be included at most once in all configured instances ofSDAP-Config with the same value of pdu-Session. For QoS flow remapping,the QFI value of the remapped QoS flow is only included inmappedQoS-FlowsToAdd in sdap-Config corresponding to the new DRB and notincluded in mappedQoS-FlowsToRelease in sdap-Config corresponding to theold DRB. mappedQoS-FlowsToRelease Indicates the list of QFIs of QoSflows of the PDU session to be released from existing QoS flow to DRBmapping of this DRB. pdu-Session Identity of the PDU session whose QoSflows are mapped to the DRB. sdap-HeaderUL Indicates whether or not aSDAP header is present for UL data on this DRB. The field cannot bechanged after a DRB is established. The network sets this field topresent if the field defaultDRB is set to true. sdap-HeaderDL Indicateswhether or not a SDAP header is present for DL data on this DRB. Thefield cannot be changed after a DRB is established.

According to 3GPP TS 23.287, a paired UEs may establish one or moreunicast links between each other. Each unicast link is associated withan Application Layer ID of a UE and an Application Layer ID of a peerUE. For each unicast link, one or more V2X services may transfer trafficthrough one unicast link. Since different V2X services require differentQoS requirements, each V2X service may have one or more PC5 QoS flowsfor traffic transfer. Therefore, each unicast link may have one or morePC5 QoS flows belonging to different V2X services. Besides, each UEneeds to maintain a mapping of PC5 QoS flow identity (PFI) to PC5 QoSContext and PC5 QoS Rules per destination associated with the unicastlink. PFI is assigned by the UE. The PC5 QoS Context includes PC5 QoSparameters (e.g. PQI, etc.), an identity used to identify a V2X service(e.g. PSID) and/or an identity used to identify a V2X application (e.g.ITS-AID) offering the V2X service for the associated PFI.

Here is an example. UE1 and UE2 establish two unicast links, UnicastLink #1 and #2. UE2 uses a first Layer-2 ID as a Destination Layer-2 ID1 for Unicast Link #1 and a second Layer-2 ID as another DestinationLayer-2 ID 2 for Unicast Link #2. On the Unicast Link #1, two V2Xservices are initialized, V2X Service A and V2X Service B. On theUnicast Link #2, two V2X services are initialized, V2X Service C and V2XService D. V2X Service A has two PC5 QoS flows, PFI1 and PFI2. V2XService B has one PC5 QoS flow, PFI3. V2X Service C has one PC5 QoSflow, PFI4. And V2X Service D has one PC5 QoS flow, PFI5.

According to the 3GPP RAN2 #106 Chairman's note, the UE, fortransmission of a new PC5 QoS flow, may report the QoS information (e.g.PQI) of the PC5 QoS flow to the gNB. And then the gNB may provide a SLRBconfiguration and configure a mapping of PC5 QoS flow to SLRB to the UEbased on the QoS information reported by the UE. Therefore, the UE maytransmit a request message to gNB to request a SLRB configuration for aPC5 QoS flow of one V2X service. In case there are multiple V2X servicessupported over the same unicast link, how to release SLRB(s) associatedwith a V2X service should be considered when this V2X service isdeactivated.

Since the mapping of PFIs to PC5 QoS Context and PC5 QoS Rules is perdestination, UE1 may send an identity or index of a destinationassociated with one or more PC5 QoS flows to the gNB to request SLRBconfiguration. The destination identity or index could be included in arequest for SLRB configuration. The destination identity or index couldbe included in a SidelinkUEInformation. The destination index mayindicate an entry in a destination list. Each entry in the destinationlist may include a destination (identified by a Destination Layer-2 ID).Based on the PQIs associated with the PC5 QoS flows, the gNB configuresthe mapping of PFIs and SLRBs. The relationship among destinationidentity/index, PFI, and PQI could be illustrated in Table 1 shown inFIG. 15.

In this example, the gNB may provide mappings of PFIs to SLRBs asfollows:

-   -   PFI1-to-SLRB1 (for V2X Service A)    -   PFI2-to-SLRB2 (for V2X Service A)    -   PFI3-to-SLRB2 (for V2X Service B)    -   PFI4-to-SLRB3 (for V2X Service C)    -   PFI5-to-SLRB4 (for V2X Service D)

PFI2 and PFI3 belong to different V2X services but the gNB may map themto SLRB2 due to e.g. PQI 2 and PQI 3 share similar PC5 QoS requirements.

It is also possible that the gNB could configure the UE1 to usedifferent SLRBs for serving different V2X services. In other words, eachSLRB is used to serve only one V2X service. To achieve this, includingV2X service type (e.g. identity of a V2X service (PSID) or identity of aV2X application offering a V2X service (ITS-AID)) in each entry of thedestination list for grouping PFIs is considered. For example, eachdestination in one entry of the destination list may be associated witha PFI list, and each entry of the PFI list includes an identity of PC5QoS flow, a PQI and a V2X service type. The relationship amongdestination identity or index, PFI, PQI and V2X service type could beillustrated in Table 2 a shown in FIG. 16.

Since V2X service type could be the identity of a V2X service or theidentity of the V2X application offering the V2X service that needs morebits for transmission, alternative for reducing signalling overhead canbe considered. The UE could group one or more PC5 QoS flows belonging tothe same V2X service as one set of PC5 QoS flow e.g. one PFI set. Eachindex or identity used to identify one PFI set could be assigned by theUE. Therefore, bits required for indicating one PFI set will be lessthan bits required for indicating one V2X service type. The index oridentity used to identify one PFI set can be included in each entry ofthe destination list. For example, each destination in one entry of thedestination list may be associated with a PFI list, and each entry ofthe PFI list includes an identity of PC5 QoS flow, a PQI and an identityor index of one PFI set. The relationship among destination identity orindex, PFI, PQI and PFI set could be illustrated in Table 2 b shown inFIG. 16.

Based on above concepts, the gNB can configure the mapping of PFIs andSLRBs as follows:

-   -   PFI1-to-SLRB1 (for V2X Service A)    -   PFI2-to-SLRB2 (for V2X Service A)    -   PFI3-to-SLRB3 (for V2X Service B)    -   PFI4-to-SLRB4 (for V2X Service C)    -   PFI5-to-SLRB5 (for V2X Service D)

When a V2X service is terminated or deactivated, the PFI(s) associatedwith the V2X service will be not needed and the SLRB(s) corresponding tothe PFI(s) should be released. For example, when the UE1 terminates theV2X Service A, the PC5 QoS flows PFI1 and PFI 2 are not needed and theSLRB(s) used to serve PFI1 and PFI2 should be released. In aboveexamples, SLRB1 used to serve PFI1 should be released. If SLRB2 is usedto serve only PFI2, it should be released; otherwise, if SLRB2 is usedto serve PFI2 and PFI3, it should not be released because SLRB2 can bestill used for traffic transfer of V2X Service B. The gNB needs to knowwhich V2X service has been terminated or deactivated by the UE or whichSLRB(s) is not needed by the UE.

In one alternative, the UE may indicate particular PC5 QoS flow(s) for adestination is not needed by updating the entry of the destination inthe destination list (e.g. removing the PFI(s) associated with thedestination and/or any information associated with the PFI(s)). If thedestination has only one V2X service that is terminated, the entry ofthe destination can be removed from the updated destination list. In theabove example, UE1 can remove PFI1 and PFI2 from the corresponding entryin the destination list and sends this updated destination list to thegNB. Based on the updated destination list, the gNB can release theSLRB(s) used to serve PFI1 and PFI2.

In one embodiment, the UE could release a SLRB and some transmissionrelated configuration (e.g. a logical channel associated with the SLRB,mapping of the logical channel to a logical channel group, and etc.) byitself if the SLRB serves one or more PC5 QoS flows belonging to thesame V2X service. Furthermore, the UE may not release a SLRB and sometransmission related configuration (e.g. a logical channel associatedwith the SLRB, mapping of the logical channel to a logical channelgroup, and etc.) by itself if the SLRB serves one or more PC5 QoS flowsbelonging to different V2X services.

In one embodiment, the UE could release a SLRB and some transmissionrelated configuration (e.g. a logical channel associated with the SLRB,mapping of the logical channel to a logical channel group, and etc.)based on an indication received from the gNB after the updateddestination list is transmitted to the gNB. The indication couldindicate which SLRB should be released. The indication could indicatethe SLRB to be released belongs to which destination. The indicationcould be a RRC (Radio Resource Control) reconfiguration message.

Examples of the updated destination list could be illustrated in thefollowing Tables 3 a-3 c shown in FIG. 17.

Alternatively, the UE could indicate the gNB about which PC5 QoS flow orwhich SLRB to be released. The UE could transmit a release message tothe gNB for releasing SLRB configuration when a V2X service isterminated. This concept may also be applied to cases where there isonly one V2X service supported on the unicast link. In this situation,each PC5 QoS flow may be deactivated or terminated by upper layersindividually and thus the SLRB mapped to the concerned PC5 QoS flow(s)may be released.

The release message may indicate a destination (via e.g. DestinationLayer-2 ID) or a unicast link (via e.g. PC5 Link Identifier) forassociating the PC5 QoS flow or SLRB to be released. The release messagemay include one or more following information:

-   -   PFI;    -   SLRB ID;    -   V2X service type (V2X service identity or V2X service index);        and    -   PFI set.

A V2X service identity is an identity of the V2X service, which may be aPSID. In addition, a UE may assign an index to a V2X service when it isactivated in the UE. For example, the UE may assign index “1” to thefirst V2X service and index “2” to the second V2X service. A V2X serviceindex is expressed with less bits than a V2X service identity and thuscould consume less signalling overhead.

By this way, the UE does not need to send the whole destination listagain so that signalling overhead can be reduced. Examples of therelease message could be illustrated in Tables 4 a-4 d shown in FIG. 18respectively, where the second entry in Table 4 b (shown in FIG. 18) ispresent if SLRB2 serves multiple V2X services and is not present ifSLRB2 serves only one V2X service.

Alternatively, the destination could not be included in the releasemessage if the PFI to be removed is differentiable among differentdestinations. Example of the release message could be illustrated inTable 5 a shown in FIG. 19.

Alternatively, the destination could not be included in the releasemessage if the SLRB to be released is differentiable among differentdestinations. Example of the release message could be illustrated inTable 5 b shown in FIG. 19. The second entry in this table is present ifSLRB2 serves multiple V2X services and is not present if SLRB2 servesonly one V2X service.

Alternatively, the destination could not be included in the releasemessage if the PFI to be removed is grouped based on V2X service type orPFI set. Examples of the release message could be illustrated in Tables5 c and 5 d shown in FIG. 19.

FIG. 20 is a flow chart 2000 according to one exemplary embodiment fromthe perspective of a first UE to indicate a network node for releasingSLRB or SL-DRB. In step 2005, the first UE transmits a first RRC messageto a network node for requesting sidelink resource, wherein the firstRRC message includes a PFI of a PC5 QoS flow in a first list of PC5 QoSflows. In step 2010, the first UE receives a second RRC message from thenetwork node, wherein the second RRC message configures a SLRB and mapsthe PC5 QoS flow to the SLRB. In step 2015, the first UE transmits athird RRC message to the network node if the PC5 QoS flow is deactivatedor released, wherein the PFI of the PC5 QoS flow is removed from asecond list of PC5 QoS flows included in the third RRC message.

In one embodiment, the PC5 QoS flow could be transmitted on a PC5unicast link and the PC5 unicast link is established between the firstUE and a second UE. The first UE could also receive a fourth RRC messagefrom the network node, wherein the fourth RRC message reconfigures theUE to release the SLRB. Furthermore, the first UE could release the SLRBaccording to the fourth RRC message.

In one embodiment, the PFI of the PC5 QoS flow may not be included inthe second list of PC5 QoS flows. The first RRC message may include adestination Layer-2 ID associated with the PC5 unicast link. Thedestination Layer-2 ID may be a Layer-2 ID of the second UE.

In one embodiment, the first RRC message or the third RRC message couldbe a SidelinkUEInformation. The second RRC message or the fourth RRCmessage could be a RRC reconfiguration message.

In one embodiment, the network node could be a base station (e.g. gNB).

Referring back to FIGS. 3 and 4, in one exemplary embodiment of a firstUE. The first UE 300 includes a program code 312 stored in the memory310. The CPU 308 could execute program code 312 to enable the first UE(i) to transmit a first RRC message to a network node for requestingsidelink resource, wherein the first RRC message includes a PFI of a PC5QoS flow in a first list of PC5 QoS flows, (ii) to receive a second RRCmessage from the network node, wherein the second RRC message configuresa SLRB and maps the PC5 QoS flow to the SLRB, and (iii) to transmit athird RRC message to the network node if the PC5 QoS flow is deactivatedor released, wherein the PFI of the PC5 QoS flow is removed from asecond list of PC5 QoS flows included in the third RRC message.Furthermore, the CPU 308 can execute the program code 312 to perform allof the above-described actions and steps or others described herein.

FIG. 21 is a flow chart 2100 according to one exemplary embodiment fromthe perspective of a UE to indicate a network node for releasing SLRB.In step 2105, the UE receives a second RRC message from the networknode, wherein the second RRC message configures a first SLRB associatedwith one or more PFIs belonging to a first V2X service or a first PFIset and a second SLRB associated with one or more PFIs belonging to asecond V2X service or a second PFI set. In step 2110, the UE transmits athird RRC message to the network node if the first V2X service isdeactivated or terminated, wherein the third RRC message indicates thefirst SLRB for release.

In one embodiment, the UE could transmit a first RRC message to thenetwork node, wherein the first RRC message includes the one or morePFIs associated with the first V2X service or the first PFI set and theone or more PFIs associated with the second V2X service or the secondPFI set. The UE could also receive a fourth RRC message from the networknode, wherein the fourth RRC message reconfigures the UE to release thefirst SLRB.

In one embodiment, the first RRC message may include a Layer-2 ID list.An entry of the Layer-2 ID list may include a first Layer-2 ID and afirst PC5 QoS flow list associated with the first Layer-2 ID, and anentry of the first PC5 QoS flow list may indicate the first V2X serviceor the first PFI set. An entry of the Layer-2 ID list may also include asecond Layer-2 ID and a second PC5 QoS flow list associated with thesecond Layer-2 ID, and an entry of the second PC5 QoS flow list mayindicate the second V2X service or the second PFI set.

In one embodiment, the first Layer-2 ID could be the same as the secondLayer-2 ID. The first PC5 QoS flow list could also be the same as thesecond PC5 QoS flow list. The first or second Layer-2 ID list could be aSource Layer-2 ID list or a Destination Layer-2 ID list. The first orsecond Layer-2 ID could also be a Source Layer-2 ID if the first/secondLayer-2 ID belongs to the UE. The first or second Layer-2 ID could be aDestination Layer-2 ID if the first or second Layer-2 ID belongs to apeer UE of the UE.

In one embodiment, the first RRC message could be a request message forSLRB configuration. The first RRC message could also be aSidelinkUEInformation. The second or fourth RRC message could be a RRCreconfiguration message.

In one embodiment, the third RRC message could be a release message forSLRB configuration. The third RRC message may include the one or morePFIs associated with the second V2X service or the second PFI set, butmay not include the one or more PFIs associated with the first V2Xservice or the first PFI set.

In one embodiment, the entry of the Layer-2 ID list including the firstLayer-2 ID and the first PC5 QoS flow list could be removed from theLayer-2 ID list in the third RRC message. The entry of the first PC5 QoSflow list indicating the first V2X service or the first PFI set could beremoved from the Layer-2 ID list in the third RRC message.

In one embodiment, the third RRC message may include an identity of thefirst SLRB. The third RRC message may also include an identity of thefirst V2X service or an identity or index of the first PFI set. The UEand the peer UE could establish a first unicast link for serving thefirst V2X service. The UE and the peer UE could also establish a secondunicast link for serving the second V2X service. The third RRC messagemay include a first PC5 Link Identifier used to identify the firstunicast link.

In one embodiment, the network node could be a base station (e.g. gNB).

Referring back to FIGS. 3 and 4, in one exemplary embodiment of a UE.The UE 300 includes a program code 312 stored in the memory 310. The CPU308 could execute program code 312 to enable the UE (i) to receive asecond RRC message from the network node, wherein the second RRC messageconfigures a first SLRB associated with one or more PFIs belonging to afirst V2X service or a first PFI set and a second SLRB associated withone or more PFIs belonging to a second V2X service or a second PFI set,and (ii) to transmit a third RRC message to the network node if thefirst V2X service is deactivated or terminated, wherein the third RRCmessage indicates the first SLRB for release. Furthermore, the CPU 308can execute the program code 312 to perform all of the above-describedactions and steps or others described herein.

FIG. 22 is a flow chart 2200 according to one exemplary embodiment fromthe perspective of a first UE to indicate a network node to releaseSLRB. In step 2205, the first UE establishes a unicast link with asecond UE to support a first sidelink service, wherein at least one SLRBare configured by the network node to support the sidelink service. Instep 2210, the first UE transmits a first RRC message, in response todeactivation of the sidelink service, to the network node, wherein thefirst RRC message includes information to indicate SLRB(s) for release.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of a firstUE. The first UE 300 includes a program code 312 stored in the memory310. The CPU 308 could execute program code 312 to enable the first UE(i) to establish a unicast link with a second UE to support a firstsidelink service, wherein at least one SLRB are configured by thenetwork node to support the sidelink service, and (ii) to transmit afirst RRC message, in response to deactivation of the sidelink service,to the network node, wherein the first RRC message includes informationto indicate SLRB(s) for release. Furthermore, the CPU 308 can executethe program code 312 to perform all of the above-described actions andsteps or others described herein.

FIG. 23 is a flow chart 2300 according to one exemplary embodiment fromthe perspective of a network node to release SLRB(s) configured to afirst UE, wherein a unicast link is established between the first UE anda second UE to support a first sidelink service. In step 2305, thenetwork node configures at least one SLRB to the first UE to support thefirst sidelink service. In step 2310, the network node receives a firstRRC message from the first UE, wherein the first RRC message includesinformation to indicate SLRB(s) for release. In step 2315, the networknode releases SLRB(s) according to the information included in the firstRRC message.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of anetwork node. The network node 300 includes a program code 312 stored inthe memory 310. The CPU 308 could execute program code 312 to enable thenetwork node (i) to configure at least one SLRB to the first UE tosupport the first sidelink service, (ii) to receive a first RRC messagefrom the first UE, wherein the first RRC message includes information toindicate SLRB(s) for release, and (iii) to release SLRB(s) according tothe information included in the first RRC message. Furthermore, the CPU308 can execute the program code 312 to perform all of theabove-described actions and steps or others described herein.

In the context of the embodiments illustrated in FIGS. 22 and 23 anddescribed above, in one embodiment, the information could be an identityor index of the first sidelink service. The information may include oneor more PC5 QoS flows (PFIs) to indicate SLRBs mapped to the one or morePC5 QoS flows (PFIs) need to be released if the SLRB(s) are not sharedby any PC5 QoS flow from other sidelink service. The information mayalso include one or more identities of the at least one SLRB if SLRB(s)identified by the one or more identities are not shared by any PC5 QoSflow from other sidelink service.

In one embodiment, the first UE could release SLRB(s) according to theinformation included in the first RRC message. Also, the first UE couldrelease SLRB(s) autonomously. The first UE could release SLRB(s) inresponse to reception of a second RRC message from the network node.

In one embodiment, the network node could transmit a second RRC messageto the first UE for SLRB release. The second RRC message may include oneor more identities of the at least one SLRB for release.

In one embodiment, the first UE could transmit a third RRC message tothe network node to request SLRB configuration(s) for one or more of theat least one SLRB. The third RRC message may include at least one PC5QoS flow (PFI). The third RRC message may also include a PC5 QoSidentifier (PQI) associated with each PC5 QoS flow. Furthermore, thethird RRC message may include an identity or index of the first sidelinkservice. In addition, the third RRC message may include a destination(Layer-2) identity and/or a PC5 Link Identifier (PFI).

In one embodiment, the network node could transmit a fourth RRC messageto the first UE to configure SLRB configuration(s) for one or more ofthe at least one SLRB. The fourth RRC message may include one or moreidentities of the at least one SLRB. The fourth RRC message may alsoinclude an identity or index of the first sidelink service. Furthermore,the fourth RRC message may include a destination (Layer-2) identityand/or a PC5 Link Identifier (PFI).

FIG. 24 is a flow chart 2400 according to one exemplary embodiment fromthe perspective of a first UE to indicate a network node to release SLRBor SL-DRB. In step 2405, the first UE receives a second RRC message fromthe network node, wherein the second RRC message configures a SLRB andmaps one or more PC5 QoS flows to be transmitted on a unicast link tothe SLRB, wherein the unicast link is established between the first UEand a second UE. In step 2410, the first UE transmits a third RRCmessage to the network node if the one or more PC5 QoS flows aredeactivated or terminated, wherein the third RRC message includesinformation indicating the SLRB for release.

In one embodiment, the first UE could transmit a first RRC message tothe network node for requesting a SLRB configuration, wherein the firstRRC message includes PFI(s) of the one or more PC5 QoS flows. The firstUE could receive a fourth RRC message from the network node, wherein thefourth RRC message reconfigures the UE to release the SLRB indicated bythe information included in the third RRC message.

In one embodiment, the first RRC message may include a destinationLayer-2 ID associated with the unicast link. The destination Layer-2 IDmay be a source Layer-2 ID of the second UE. The first or third RRCmessage may be a SidelinkUEInformation. The second or fourth RRC messagemay be a RRC reconfiguration message.

In one embodiment, the third RRC message may be a release message forthe SLRB. The third RRC message may include PFIs of the one or more PC5QoS flows mapped to the SLRB for release. The third RRC message mayinclude an identity of the SLRB for release or an index of aconfiguration configuring the SLRB for release.

In one embodiment, the network node could be a base station (e.g. gNB).

In one embodiment, the first UE could release the SLRB according to theinformation included in the fourth RRC message. The first UE couldrelease SLRB(s) autonomously.

In one embodiment, the third RRC message could be transmitted to thenetwork node if upper layer of the first UE indicates the one or morePC5 QoS flows are deactivated or terminated or if upper layer of thefirst UE indicates the one or more PC5 QoS flow are not mapped to theSLRB. The one or more PC5 QoS flows may be associated with a V2Xservice. The third RRC message could indicate the PFIs of the one ormore PC5 QoS flows mapped to the SLRB are removed from a list of PC5 QoSflow included in the first RRC message.

In one embodiment, the first RRC message may include PFI(s) of the oneor more PC5 QoS flows. The first RRC message may also include a PC5 QoSidentifier (PQI) and/or a PC5 QoS profile associated with each PC5 QoSflow. Furthermore, the first RRC message may include a destination(Layer-2) identity and/or a PC5 Link Identifier (PFI) associated withthe unicast link.

In one embodiment, the second RRC message may include one or moreidentities of the at least one SLRB. The second RRC message may includea destination (Layer-2) identity, an index associated with thedestination (Layer-2) identity and/or a PC5 Link Identifier (PFI)associated with the unicast link.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of a firstUE. The first UE 300 includes a program code 312 stored in the memory310. The CPU 308 could execute program code 312 to enable the first UE(i) to receive a second RRC message from the network node, wherein thesecond RRC message configures a SLRB and maps one or more PC5 QoS flowsto be transmitted on a unicast link to the SLRB, wherein the unicastlink is established between the first UE and a second UE, and (ii) totransmit a third RRC message to the network node if the one or more PC5QoS flows are deactivated or terminated, wherein the third RRC messageincludes information indicating the SLRB for release. Furthermore, theCPU 308 can execute the program code 312 to perform all of theabove-described actions and steps or others described herein.

FIG. 25 is a flow chart 2500 according to one exemplary embodiment fromthe perspective of a network node to release SLRB(s) configured to afirst UE. In step 2505, the network node configures at least one SLRB tothe first UE for a unicast link, wherein the unicast link is establishedbetween the first UE and a second UE. In step 2510, the network nodereceives a third RRC message from the first UE, wherein the third RRCmessage includes information to indicate a SLRB among the at least oneSLRB for release. In step 2515, the network node releases configurationsof the SLRB according to the information included in the third RRCmessage.

In one embodiment, the information may include PFI(s) of one or more PC5QoS flows mapped to the SLRB for release. The information may alsoinclude an identity of the SLRB for release.

In one embodiment, the network node could transmit a fourth RRC messageto the first UE for SLRB release. The fourth RRC message may include oneor more identities of the SLRB for release.

In one embodiment, the first UE could transmit a first RRC message tothe network node to request SLRB configuration(s) for the one or morePC5 QoS flows. The first RRC message may include PFI(s) of the one ormore PC5 QoS flows. The first RRC message may also include a PC5 QoSidentifier (PQI) and/or a PC5 QoS profile associated with each PC5 QoSflow. Furthermore, the first RRC message may include a destination(Layer-2) identity and/or a PC5 Link Identifier (PFI) associated withthe unicast link.

In one embodiment, the information may indicate the PFIs of the one ormore PC5 QoS flows mapped to the SLRB are removed from a list of PC5 QoSflow included in the first RRC message.

In one embodiment, the network node could transmit a second RRC messageto the first UE to configure SLRB configuration(s) for one or more ofthe at least one SLRB. The second RRC message may include one or moreidentities of the at least one SLRB. The second RRC message may alsoinclude a destination (Layer-2) identity, an index associated with thedestination (Layer-2) identity and/or a PC5 Link Identifier (PFI)associated with the unicast link.

In one embodiment, the first or third RRC message may be aSidelinkUEInformation. The second or fourth RRC message may be a RRCreconfiguration message.

Referring back to FIGS. 3 and 4, in one exemplary embodiment of anetwork node. The network node 300 includes a program code 312 stored inthe memory 310. The CPU 308 could execute program code 312 to enable thenetwork node (i) to configure at least one SLRB to the first UE for aunicast link, wherein the unicast link is established between the firstUE and a second UE, (ii) to receive a third RRC message from the firstUE, wherein the third RRC message includes information to indicate aSLRB among the at least one SLRB for release, and (iii) to releaseconfigurations of the SLRB according to the information included in thethird RRC message. Furthermore, the CPU 308 can execute the program code312 to perform all of the above-described actions and steps or othersdescribed herein.

Various aspects of the disclosure have been described above. It shouldbe apparent that the teachings herein could be embodied in a widevariety of forms and that any specific structure, function, or bothbeing disclosed herein is merely representative. Based on the teachingsherein one skilled in the art should appreciate that an aspect disclosedherein could be implemented independently of any other aspects and thattwo or more of these aspects could be combined in various ways. Forexample, an apparatus could be implemented or a method could bepracticed using any number of the aspects set forth herein. In addition,such an apparatus could be implemented or such a method could bepracticed using other structure, functionality, or structure andfunctionality in addition to or other than one or more of the aspectsset forth herein. As an example of some of the above concepts, in someaspects concurrent channels could be established based on pulserepetition frequencies. In some aspects concurrent channels could beestablished based on pulse position or offsets. In some aspectsconcurrent channels could be established based on time hoppingsequences. In some aspects concurrent channels could be establishedbased on pulse repetition frequencies, pulse positions or offsets, andtime hopping sequences.

Those of skill in the art would understand that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Those of skill would further appreciate that the various illustrativelogical blocks, modules, processors, means, circuits, and algorithmsteps described in connection with the aspects disclosed herein may beimplemented as electronic hardware (e.g., a digital implementation, ananalog implementation, or a combination of the two, which may bedesigned using source coding or some other technique), various forms ofprogram or design code incorporating instructions (which may be referredto herein, for convenience, as “software” or a “software module”), orcombinations of both. To clearly illustrate this interchangeability ofhardware and software, various illustrative components, blocks, modules,circuits, and steps have been described above generally in terms oftheir functionality. Whether such functionality is implemented ashardware or software depends upon the particular application and designconstraints imposed on the overall system. Skilled artisans mayimplement the described functionality in varying ways for eachparticular application, but such implementation decisions should not beinterpreted as causing a departure from the scope of the presentdisclosure.

In addition, the various illustrative logical blocks, modules, andcircuits described in connection with the aspects disclosed herein maybe implemented within or performed by an integrated circuit (“IC”), anaccess terminal, or an access point. The IC may comprise a generalpurpose processor, a digital signal processor (DSP), an applicationspecific integrated circuit (ASIC), a field programmable gate array(FPGA) or other programmable logic device, discrete gate or transistorlogic, discrete hardware components, electrical components, opticalcomponents, mechanical components, or any combination thereof designedto perform the functions described herein, and may execute codes orinstructions that reside within the IC, outside of the IC, or both. Ageneral purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

It is understood that any specific order or hierarchy of steps in anydisclosed process is an example of a sample approach. Based upon designpreferences, it is understood that the specific order or hierarchy ofsteps in the processes may be rearranged while remaining within thescope of the present disclosure. The accompanying method claims presentelements of the various steps in a sample order, and are not meant to belimited to the specific order or hierarchy presented.

The steps of a method or algorithm described in connection with theaspects disclosed herein may be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module (e.g., including executable instructions and relateddata) and other data may reside in a data memory such as RAM memory,flash memory, ROM memory, EPROM memory, EEPROM memory, registers, a harddisk, a removable disk, a CD-ROM, or any other form of computer-readablestorage medium known in the art. A sample storage medium may be coupledto a machine such as, for example, a computer/processor (which may bereferred to herein, for convenience, as a “processor”) such theprocessor can read information (e.g., code) from and write informationto the storage medium. A sample storage medium may be integral to theprocessor. The processor and the storage medium may reside in an ASIC.The ASIC may reside in user equipment. In the alternative, the processorand the storage medium may reside as discrete components in userequipment. Moreover, in some aspects any suitable computer-programproduct may comprise a computer-readable medium comprising codesrelating to one or more of the aspects of the disclosure. In someaspects a computer program product may comprise packaging materials.

While the invention has been described in connection with variousaspects, it will be understood that the invention is capable of furthermodifications. This application is intended to cover any variations,uses or adaptation of the invention following, in general, theprinciples of the invention, and including such departures from thepresent disclosure as come within the known and customary practicewithin the art to which the invention pertains.

The invention claimed is:
 1. A method for a first UE (User Equipment) to indicate a network node for releasing SLRB (Sidelink Radio Bearer) or SL-DRB (Sidelink-Data Radio Bearer), comprising: transmitting a first RRC (Radio Resource Control) message to a network node for requesting sidelink resource, wherein the first RRC message includes a PFI (PC5 QoS Flow Identifier) of a PC5 QoS (Quality of Service) flow in a first list of PC5 QoS flows; receiving a second RRC message from the network node, wherein the second RRC message configures a SLRB and maps the PC5 QoS flow to the SLRB; and transmitting a third RRC message to the network node if the PC5 QoS flow is deactivated or released, wherein the PFI of the PC5 QoS flow is not included in a second list of PC5 QoS flows included in the third RRC message.
 2. The method of claim 1, wherein the PC5 QoS flow is to be transmitted on a PC5 unicast link and the PC5 unicast link is established between the first UE and a second UE.
 3. The method of claim 1, further comprising: receiving a fourth RRC message from the network node, wherein the fourth RRC message reconfigures the UE to release the SLRB.
 4. The method of claim 3, further comprising: releasing the SLRB according to the fourth RRC message.
 5. The method of claim 1, wherein the first RRC message includes a destination Layer-2 ID associated with the PC5 unicast link.
 6. The method of claim 5, wherein the destination Layer-2 ID (Identity) is a Layer-2 ID of the second UE.
 7. The method of claim 1, wherein the first RRC message or the third RRC message is a SidelinkUEInformation.
 8. The method of claim 1, wherein the second RRC message or the fourth RRC message is a RRC reconfiguration message.
 9. The method of claim 1, wherein the network node is a base station.
 10. A first UE (User Equipment), comprising: a control circuit; a processor installed in the control circuit; and a memory installed in the control circuit and operatively coupled to the processor; wherein the processor is configured to execute a program code stored in the memory to: transmit a first RRC (Radio Resource Control) message to a network node for requesting sidelink resource, wherein the first RRC message includes a PFI (PC5 QoS Flow Identifier) of a PC5 QoS (Quality of Service) flow in a first list of PC5 QoS flows; receive a second RRC message from the network node, wherein the second RRC message configures a SLRB (Sidelink Radio Bearer) and map the PC5 QoS flow to the SLRB; and transmit a third RRC message to the network node if the PC5 QoS flow is deactivated or released, wherein the PFI of the PC5 QoS flow is not included in a second list of PC5 QoS flows included in the third RRC message.
 11. The first UE of claim 10, wherein the PC5 QoS flow is to be transmitted on a PC5 unicast link and the PC5 unicast link is established between the first UE and a second UE.
 12. The first UE of claim 10, wherein the processor is further configured to execute a program code stored in the memory to: receive a fourth RRC message from the network node, wherein the fourth RRC message reconfigures the UE to release the SLRB.
 13. The first UE of claim 12, wherein the processor is further configured to execute a program code stored in the memory to: release the SLRB according to the fourth RRC message.
 14. The first UE of claim 10, wherein the first RRC message includes a destination Layer-2 ID associated with the PC5 unicast link.
 15. The first UE of claim 14, wherein the destination Layer-2 ID is a Layer-2 ID of the second UE.
 16. The first UE of claim 10, wherein the first RRC message or the third RRC message is a SidelinkUEInformation.
 17. The first UE of claim 10, wherein the second RRC message or the fourth RRC message is a RRC reconfiguration message.
 18. The first UE of claim 10, wherein the network node is a base station. 